Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run /usr/lib/ostree-boot/setup.sh if it exists during u-boot bootloader setup #2416

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jallwine
Copy link

@jallwine jallwine commented Aug 20, 2021

Standard Beaglebone images have a custom version of U-Boot installed that looks for specific variables in the uEnv.txt file as well as specific files for loading various device tree overlays. In order to properly set up the /boot/loader.# directory at ostree admin deploy time, I added a check for the existence of /usr/lib/ostree-boot/setup.sh in the deployment and run it so it can set up the necessary symlinks and modifications to uEnv.txt (this is much easier than implementing it explicitly in C). The script is passed the sysroot path, the deployment path, and the /boot/loader.# path so that it can properly set everything up. If the script fails to run (not executable, for example) or exits with an error status, the deployment will fail.

See #2357 for more info.

Here is an example setup.sh script that I use for the Beaglebone:

#!/bin/bash

SYSROOT=$1
DEPLOY=$2
LOADER=$3

echo "PWD: $PWD"
echo "SYSROOT: $SYSROOT"
echo "DEPLOY: $DEPLOY"
echo "LOADER: $LOADER"

cd ${SYSROOT}${LOADER}

cp ${SYSROOT}${DEPLOY}/boot/uEnv.txt uEnv.txt
sed -i "/^cmdline=/ s,$, ostree=${DEPLOY}," uEnv.txt

ln -s ${DEPLOY}/boot/vmlinuz-current
ln -s ${DEPLOY}/boot/initrd.img-current
ln -s ${DEPLOY}/boot/dtbs
ln -s ${DEPLOY}/boot/System.map-current
ln -s ${DEPLOY}/boot/config-current
ln -s ${DEPLOY}/boot/SOC.sh
ln -s ${DEPLOY}/boot/uboot
ln -s ${DEPLOY}/boot/lib

during ostree admin deploy after the uEnv.txt file has been
written. setup.sh could write out a whole new uEnv.txt file
and/or write out other files/symlinks. The script is passed
the sysroot path, the ostree deployment path and the
boot/loader.# path, so it can make the proper links.
@openshift-ci
Copy link

openshift-ci bot commented Aug 20, 2021

Hi @jallwine. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@lucab
Copy link
Member

lucab commented Aug 23, 2021

/ok-to-test

@dbnicholson
Copy link
Member

There are 2 parts I'd like to think about before adding this.

  1. @jallwine what does your setup.sh actually do? Anything that can be done with the builtin loader is better for everyone so that they don't have to go implement a separate program to get things deployed. An escape hatch is nice, but I'd rather see ostree work out of the box. Maybe the semantics of the loader just need to be better documented.
  2. If the external program is determined to be needed, we really want to think about what the semantics are and what the interface to that program is. Changing it later would be painful since it could make existing deployments unable to upgrade.

@jallwine
Copy link
Author

jallwine commented Aug 23, 2021

Thanks for taking a look @dbnicholson! I agree we should discuss further. I'm not sure if I'm doing it the best way, but it seems to work. I went this route due to how Beaglebone's custom version of U-Boot works. A lot of the custom U-Boot code is here: https://github.com/beagleboard/u-boot/blob/v2019.04-bbb.io-am335x/include/configs/ti_armv7_common.h The key pieces are under the uname_boot variable when it detects a uname_r variable set in the uEnv.txt file.

  1. My setup.sh script copies the deployment's uEnv.txt file over to the proper /boot/loader.#/uEnv.txt. It overwrites what the ostree uboot configuration generated because I'm only concerned with the variables used by Beaglebone's custom version of U-Boot (this is why I was originally leaning towards creating a new bootloader configuration). All I need to change in my uEnv.txt file is add the ostree= to the cmdline argument. This is handled by these two lines:
cp ${SYSROOT}${DEPLOY}/boot/uEnv.txt uEnv.txt
sed -i "/^cmdline=/ s,$, ostree=${DEPLOY}," uEnv.txt

The rest of the lines create symlinks so that Beaglebone's custom U-Boot can find specific paths at boot. In most Beaglebone uEnv.txt files, there's a uname_r variable that should be set to the kernel version of the system. uname_r is used in a number of paths in U-Boot. These paths include /lib/firmware and /boot. When preparing my rootfs, I set the uname_r variable to always be the value current rather than a specific kernel version and then create the proper symlinks to the actual kernel verison (i.e. symlink vmlinuz-current to vmlinuz-4.19.94-ti-r43), initramfs (initrd.img-4.19.94-ti-r43 -> initrd.img-current). There's also a dtbs/<kernel version> folder that contains a number of device tree overlays that can be pulled in at boot by setting specific variables (disable_uboot_overlay_emmc, disable_uboot_overlay_video, disable_uboot_overlay_audio, disable_uboot_overlay_wireless, and disable_uboot_overlay_adc). Again, I symlink that directory to dtbs/current. What's problematic is the real sysroot of the filesystem needs to have symlinks from files in /lib/firmware to the /lib/firmware in the deployment as well as symlinks from files in /boot to the deployment. So, on the real /sysroot I also created symlinks from /lib to /boot/loader/lib and /boot/vmlinuz-current to /boot/loader/vmlinuz-current, /boot/initrd.img-current to /boot/loader/initrd.img-current, etc. With it set up this way, ostree admin deploy needs to create the symlinks from /boot/loader.#/vmlinuz-current to the deployment's /boot/vmlinuz-current (and the initrd, dtbs folder, etc.). My setup.sh script creates those /boot/loader.# links.

  1. I pass in the sysroot path, the deployment path and the /boot/loader.# path as the first three arguments to setup.sh. That way the script has the ability to create links however it needs to whether ostree admin deploy is run from a build process or on a client.

Any thoughts you have on the best way forward are appreciated!

@jallwine
Copy link
Author

jallwine commented Aug 24, 2021

Oh, and there’s one other thing that’s been in the back of my mind, but I haven’t implemented yet in the setup.sh. The U-Boot build does get updated occasionally and needs to be written to the first portion of the Beaglebone’s eMMC (I’ve run into complications with certain device tree overlays when updating them, but didn’t update U-Boot). There’s a script that does this in any given deployment so it seems appropriate to run it from setup.sh during an ostree admin deploy. I would only want to run that piece on the client, and not on the build system.

@jowa2021
Copy link

Hello.
I am not a master like most of you here, but this seems dangerous and deceitful. Maybe I misinterpreted everything I have read here, so, can someone please help me understand more clearly ?
Would it be wrong for me to summarize this by saying that this potentially could be used to trick another individual into thinking they were looking at one thing, but its actually another ??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants